Admission Controller

译者:Nancy 校对:无

目录

  • Admission Controller『参见以下内容』
    • Admission Controller是什么?『参见下文“什么是Admission Controller”』
    • 为什么使用Admission Controller?『参见下文“为什么使用Admission Controller”』
    • 如何使用接入控制插件?『参见下文“如何接入该插件”』
    • 每个插件的功能『参见下文“每个插件的功能是什么”』
    • AlwaysAdmit『参见下文“AlwaysAdmin插件”』
    • AlwaysDeny『参见下文“AlwaysDeny插件”』
    • DenyExecOnPrivileged (废弃)『参见下文“DenyExecOnPrivileged (废弃)插件”』
    • DenyEscalatingExec『参见下文“DenyEscalatingExec插件”』
    • ServiceAccount『参见下文“ServiceAccount插件”』
    • SecurityContextDeny『参见下文“SecurityContextDeny插件”』
    • ResourceQuota『参见下文“ResourceQuota插件”』
    • LimitRanger『参见下文“LimitRanger插件”』
    • NamespaceExists (废弃)『参见下文“NamespaceExists(废弃)插件”』
    • NamespaceAutoProvision (废弃)『参见下文“NamespaceAutoProvision (废弃)插件”』
    • NamespaceLifecycle『参见下文“NamespaceLifecycle插件”』
    • 是否有推荐的插件集合?『参见下文“是否有推荐的插件集合”』

什么是Admission Controller?

Admission Controller插件是一段代码,其拦截Kubernetes API服务的请求早于对象的持久性,但是在请求的认证和授权之后。插件代码位于API服务进程中,会编译成二进制以便此时使用。

集群在接受一个请求之前,每一个Admission Controller插件都会按序运行。如果这个序列中的某个插件拒绝该请求,则整个的请求都会被立刻拒绝,返回一个错误给用户。

Admission Controller插件在某些情况下也许会改变传进来的对象,配置系统默认值。此外,Admission Controller插件也许会改变请求处理中的部分相关资源去做些事情,比如增量配额的使用。

为什么使用Admission Controller?

Kubernetes中许多高级功能需要激活Admission Controller插件,以便更好的支持该功能。总之,没有正确配置Admission Controller插件的Kubernetes API服务是不完整的服务,很多用户期望的服务是不支持的。

如何接入该插件?

Kubernetes API 服务器提供了一个参数,admission-control,用逗号分隔,在集群中修改对象之前,调用许可控制选项的有序列表。

每个插件的功能是什么?

AlwaysAdmin插件**

使用插件本身处理所有请求。

AlwaysDeny插件**

拒绝所有请求,主要用于测试。

DenyExecOnPrivileged (废弃)插件**

如果一个Pod有一个特权Container,该插件就会拦截所有的请求,在该Pod中执行一个命令。

如果你的集群支持特权Container,而且你想要限制终端用户在那些Container中执行命令的权限,我们强烈建议使用该插件。

该功能已经合并到DenyEscalatingExec插件『参见下文“DenyEscalatingExec插件”』)

DenyEscalatingExec插件**

该插件拒绝执行和附加令到允许主机访问的且有升级特权的Pod。包含含有运行特权的Pod,有访问主机PID Namespace的权限。

如果你的集群支持含有升级特权的Container,而且你想要限制终端用户在这些Container中执行命令的能力,我们强烈建议使用该插件。

ServiceAccount插件**

这个插件实现了serviceAccounts的自动化。如果你打算使用Kubernetes ServiceAccount对象,我们强烈建议使用该插件。

SecurityContextDeny插件**

SecurityContext定义了一些不适用于Container的选项,这个插件将会拒绝任何含有该SecurityContext的Pod。

ResourceQuota插件**

该插件会检查传入的请求,确保其不违反任何Namespace中ResourceQuota对象枚举的约束条件。如果你在Kubernetes开发中正在使用ResourceQuota对象,你必须使用该插件实现配额约束条件。

查看resourceQuota设计文档Resource Quota示例了解更多细节。

强烈建议配置该插件在Admission Controller插件的序列中。This is so that quota is not prematurely incremented only for the request to be rejected later in admission control。(该句话翻译有待考虑)

LimitRanger插件**

该插件会检查传入的请求,确保其不违反任何Namespace中LimitRange对象枚举的约束条件。如果你在Kubernetes开发中正在使用LimitRange对象,你必须使用该插件实现约束条件。LimitRange也经常用于Pod中默认资源请求,不会指定哪一个请求。目前,默认LimitRange,在默认的Namespace中对所有的Pod,需要0.1CPU。

查阅LimitRange设计文档用例,了解更多详细信息。

NamespaceExists(废弃)插件**

该插件会检查所有传入的请求,尝试在Kubernetes Namespace中创建资源,如果该Namespace不是当前创建的,该插件会拒绝这个请求。我们强烈建议使用该插件,确保数据的完整性。

Admission Controller的该功能已经并入NamespaceLifecycle插件。

NamespaceAutoProvision (废弃)插件**

该插件会检查所有传入的请求,尝试在Kubernetes Namespace中创建资源,如果Namespace不存在,会创建一个新的Namespace。

我们强烈建议NamespaceExists插件优先级高于NamespaceAutoProvision插件。

NamespaceLifecycle插件**

如果Namespace已经终止,则不能在其中创建新的Namespace,该插件会强制该操作。

删除一个Namespace会终止一系列操作,移除该Namespace中所有对象(Pod,服务等等)。为了加强该过程的完整性,我们建议使用该插件。

是否有推荐的插件集合?

是的。

Kubernetes1.0,我们强烈建议使用如下的许可控制插件集合(按顺序排列):

--admission_control=NamespaceLifecycle,NamespaceExists,LimitRanger,SecurityContextDeny,ServiceAccount,ResourceQuota